The following description relates to server session management and backwards navigation from a browser in a stateful server session.
A portal is a mechanism by which various web content can be assembled into one or more portal pages delivered to a client and displayed in a browser application running on the client. The portal pages are typically delivered from a server according to the hypertext transfer protocol (HTTP). A web application is a separate callable unit stored on any server, and typically called via uniform resource locator (URL) address. On the portal level, the callable unit and its content is sometimes called a portlet (also called pagelets, iViews, webparts, etc.). Thus, an application appears as a portlet, which is assembled onto one or more web pages according to a page layout scheme. Pages are the navigation units in a portal, i.e. the user always navigates to a page, which then calls all the portlets on that page.
For simplicity, assume that a portlet is isolated, i.e. the content runs inside a page structure called an IFRAME. A user can navigate around a portlet in several ways, such as “clicking” inside the portlet using a mouse device and/or pointer. For intra-application-navigation (e.g. navigation to a “next screen”), the user is considered “inside” an application which doesn't affect the page level around the portlet or application. When the user navigates on the portal level, the user also selects a new portal page or even the same portal page as a target. When that occurs, the old portal page is displaced in the browser, as is the portlet containing an application. Accordingly, the user “leaves an application” when he or she leaves the portal page that contains an application.
State in Web Applications
Web-based applications consist of a sequence of pages delivered from a server to a client. When a user navigates through the sequence of pages, the server maintains “state,” i.e. retains data about user input on previously viewed pages, navigation history, and data needed by the application to respond to the user, etc. State is typically kept in a session by the server, and identified for each session by a session identifier (“sessionID”) generated by the server. The sessionIDs can be kept in a browser “cookie” (information for future use that is sent by the server and stored on the client) or in a URL included in the server response. All non-trivial applications need server state to be able to respond quickly to user request. Therefore, most business applications on the web are “stateful.”
Normally, there can only be one session per user and/or per browser process. A web application is “multi-session enabled” when a user can run two or more instances of the same application at the same time—in the extreme case side-by-side in two IFRAMEs in the same browser window. Multi-session applications are started with a “start-URL” that has no sessionID, and then the server creates a session and maintains the session association by putting the sessionID in URLs (URL rewriting) or in cookies. A truly multi-session enabled application cannot use cookies for sessionIDs since the cookies would overwrite each other when they meet in the same browser window (process), and there is no way for the server to distinguish between the two parallel requests that come from two IFRAMEs in the same browser. Thus, multi-session capability requires sessionIDs to be encoded in URLs. This causes a complication for “session-return” that will be described further below.
One issue appears in the combination of multi-session and page “back” navigation. To allow multi-session capability, session IDs must be encoded in URLs, which means that a portal page contains a start URL, and then server responds with a new session for each applications instance. But when the user comes “back” to the same page, the same start URLs are fired, and the server again has no way to distinguish between the two instances in the two IFRAMEs on the page.
Basic Session Termination
One method for server session termination is described in related U.S. application Ser. No. 09/614,167, filed on Jul. 11, 2000, and entitled, “Method, Apparatus and System for Network-Based Peer-to-Peer Business Transactions”, which is incorporated by reference herein. The system scenario is a portal calling web applications.
Users enter applications and request pages/screens from server-based applications. Applications need resources such as “session state” to perform requested dialogue or online transactions, possibly need to acquire locks or other critical resources during some part of a transaction. When the user leaves the application in the middle of a transaction, the server does not technically notice, since HTTP is connectionless, and this can happen by navigating to another portal page, or even simply closing the browser. When the user does not explicitly terminate the application, such as when the user logs off from the session, the server's session state (and possibly even locks) are kept on the server, wasting resources until timeout. Therefore, the portal must notify the server and/or application when the user leaves the application, so that the server can release the resources associated with the application.
Basic session termination works as follows: the portal provides a Session Manager (SM) that runs partly hidden in the portal/browser. When an application is started inside a portal page, as part of its response in the hypertext markup language it sends a “session termination URL” to the SM. When the current page is displaced and the SM has stored a session termination URL for the current page, this session termination URL is sent back to the server so that the server can then release the session and all its associated resources. This is how the server gets “notified” that the application was left, and its resources should be released.
The Need for Session-Return Enabling
The “Basic Session Termination” described above terminates the session as soon as the user leaves the application, i.e. when the user jumps to another page by navigation, or by browser shortcut, etc. However, users typically want to be able to explore various pages of a second application or page, and then go back to a previously-visited page/application and continue working there. In essence, users want stateful applications, that are often exposed in portals, to behave mostly like static content with respect to the “back” function in the browser.
One problem is that it is not known whether the user will ever come back to the first page/application, which means that the server needs to immediately be notified when the user leaves the application, and then releases its session state at that time. Therefore, one issue includes modifying the Basic Session Termination concept to allow a “Session-Return,” i.e. the ability of a user to return to a previous-visited session in the same state as when the user left the session.
Thus, applications cannot be allowed to simply “wait” to return or continue later, but must indeed terminate immediately when the user leaves. In order to be able to return, the application would need to first store whatever part of the state is necessary to return. It is undesirable to store the full internal state, or the state of some other form, such as storing all user interface fields for example. Further, an application cannot be expected to store its full current state at any given time, so that any working intermediate state can be saved fully. Thus, the persistent part of the session state will be stored and the transient state will be discarded. The state that is stored persistently is called the “session return state,” and would generally include the IDs of the objects being shown/edited, as well as possibly some UI state, such as which tab is active in a tab strip, the open-closed state of trees, etc. Restarting the application with these parameters reloaded from the session return state will give the desired “back” or session-return perception to the user, and the application enough data to restart itself with that data.
Thus, it can be assumed that the application is able to store its session return state when it receives a termination request, and can be restarted such that it will reload the previous session return state to show substantially the same output as when the user left. However, this means that the interpretation of the termination request of the Basic Session Termination concept has changed from “completely terminate” to “store session return state and then terminate.” This new interpretation can be called “session minimize.” How much an application stores in the session return state is variable and up to the application. In a case where nothing is kept, the session minimize is the same as the conventional terminate completely—in which the application restarts from scratch each time.
When an application has been restarted, and the “session return state” has been loaded, a problem occurs when multiple instances of the application are active at the same time. The server will not know which “session return state” to load when restarting the application. The problem exists regardless whether the application is started in separate browser windows or even in the same browser window (i.e. inside two IFRAMEs in a portal page, etc.).